Computers manipulate data in accordance with programs of instructions. The purpose(s) served by a computer is determined by the application program or programs running on that computer. Rather than running directly on computer hardware, application programs typically run on an operating system that serves as a standard interface between applications programs and hardware. Thus, application developers can develop for a single interface defined by the operating system, while the operating system developer and hardware developers work to ensure compatibility between the hardware and the operating system. Thus, when a new piece of hardware is introduced, e.g., a new peripheral, it would come with a driver program that would enable the operating system to use the peripheral.
The task of the hardware developer has been complicated by the existence of different operating systems. Typically, each operating system would require a separate driver—either to work with the hardware at all or at least to work with it optimally. The task of developing, testing and supporting multiple drivers for multiple operating systems add to the cost and the development time for hardware.
The “Extensible Firmware Interface” is an industry standard basic input-output system (BIOS) layer between the operating system and hardware that does for hardware what operating systems did for application programs. The EFI is software loaded from firmware, e.g., flash memory, upon system start up. Once loaded, it takes control of the boot process. Generally, the EFI layer provides a single interface for which hardware drivers are designed. Operating system developers of course have to provide compatibility with the EFI.
When a computer is powered on or restarted, the operating system must be found and launched before any application programs can be run. Some computers provide only a single location for an operating system, so finding the operating system is not an issue. Other computers provide a prioritized list of locations at which an operating system can be found. In those system, the first location in the list (Storage device A:, Storage device B:, Storage device C:, etc.) to have an operating system is the one used to boot the operating system. Storage devices divided into logical partitions are searched partition-by-partition.
The “Small Computer Systems Interface” or “SCSI” provides a way to expand the storage device storage of a computer. By installing a SCSI interface, one could add a number of SCSI-compatible devices, such as hard storage devices. A boot routine would query the SCSI interface, which would check each possible SCSI location to see if it was populated with some device. At the end of this routine, a list of available devices could be used to guide the search for an operating system. If there were multiple such SCSI interfaces, they could be queried in turn for available storage devices.
Enterprise servers often have large numbers of storage devices attached (internal or SAN). Configuring the boot storage devices on EFI-based servers with large numbers of storage devices presents challenges for usability, deployment, and provisioning. When a sequential approach to enumeration is scaled to such large systems, the latency involved in storage device enumeration can be costly. In a large data center, there can be tens of thousands of storage devices that would take hours to enumerate serially.
Rather than accept this delay, the possible locations of an operating system can be identified manually. An administrator could do the configuring during a boot up sequence using a special monitor program, or it could be done through the operating system, with the target storage device identities stored in a configuration file available to the boot routine. While this greatly reduces the latency associated with boot up, it imposes a burden on computer administration. Manual interaction could be complicated if storage device interfaces (“host bus adapters”) were provided from different manufacturers using different proprietary interfaces for manual enumeration. What is needed is a fast automated approach to storage device enumeration.
Herein, related art is described to facilitate understanding of the invention. Related art labeled “prior art” is admitted prior art; related art not labeled “prior art” is not admitted prior art.